Computer applications continue to play an increasingly important role in the lives of individuals. Additionally, the desire by end-users for bigger, better and faster applications has also increased.
Unfortunately for application development teams, the applications have increased in complexity. As a result of this complexity, the time to develop applications has also increased. The demand for bigger, better and faster applications is often combined with the requirement that these new applications be provided to the market in ever shorter time frames.
As will be apparent, the market forces to develop bigger, better and faster applications in ever shorter times is in direct competition with the development team's need for longer times to develop these same applications. Accordingly, tools to assist a developer or development team in shortening the development cycle are desired.
In the present development environment, different models often represent the same data but in different formats. A model may be a collection of objects. The objects may, or may not, be of the same type.
For an example of the same data in different formats, consider the source code of an application under development. The source code, which forms a source object, is sometimes represented in two models: a model of files, and a model of objects. The data contained in the file is the same data that is contained in the object. To be specific, because the source file is code, each object, in the model of objects, is a metadata object. In information technology, the prefix “meta” often means “a description of”. Metadata is a description of data; and in this example, metadata would name the parts of the source code: fields, methods, etc. Fields and methods are defined in the following paragraph.
In object oriented programming, an object often models a “real life” entity. For example, an object may be created to describe a rectangle. Variables or “fields” are identified to represent characteristics of all rectangles, namely the length and width. Procedures (known in the art as methods) would be present in the object to manipulate the length and width to generate other characteristics such as perimeter and area of a rectangle.
A model may comprise many different source code files. In fact, it is not uncommon for complex applications to comprise several million lines of source code distributed among thousands of separate files. Each source code file may describe several objects.
For the purpose of this document, “notify model” is used to represent a model(s) which, when changed, results in a signal, known as an “event notification”, being issued which indicates that a change has occurred. “Target model” is used to represent a model(s) which, when a change has occurred in the notify model, either changes in response to that change, or is changed concurrently with the notify model change. As will be appreciated, the notification of a change only operates in one direction from the notify model to the target model.
It is known to those skilled in the art that programming code can be written, especially in object-oriented languages, to receive event notifications (i.e., the programming code is notified when certain changes occur).
Depending on the context, both source models and object models can be either a notify model, or a target model. To assist in the understanding of the notify and target models, the following examples illustrate three scenarios. In the first exemplary scenario, a file in the source model is changed and an object model is modified in response to the file change. In this first exemplary scenario the source model is the notify model, and the object model is the target model. In a second exemplary scenario a developer's tool changes an object model which causes new source code files to be created. In this second exemplary scenario the object model is the notify model, and the source model is the target model. In a third exemplary scenario source code is used as input for a tool. The tool generates new source code files, and, due to the existence of new code, an object model is updated. In this third exemplary scenario, the source code is both a notify and target model, and the object model is a target model.
As will be appreciated, a single instance of a notify model may consist of several models. Similarly, an instance of a target model may also consist of several models.
The notify and target model is exemplified in the use of computer code generators. Many applications presently exist to assist developers in generating code which, for many functions, is relatively easy to complete but quite time consuming to code and test. As a result of the laborious nature of producing some code, automatic code generators have been created. These automatic code generators, which often use a visual representation, or model, of the desired output, generate code which represents the graphical model produced.
For example, writing computer code for a graphical user interface (GUI), such as those common to most users of the Microsoft Windows operating system, is quite time consuming. To assist developers in generating the code for a GUI, automatic code generators have been created. These GUI code generators allow developers to work in a graphical development environment and select various user interface controls (e.g., radio buttons, drop down list boxes, selection boxes, etc.), typically using a “drag and drop” mechanism, and place the user interface controls in the graphical development environment representing a screen image to be presented to a user. When the developer has completed the graphical appearance, the developer instructs the development environment to generate the code which will implement the graphical representation created. In this example, the graphical representation of the user interface interacts with the object notify model, and the code automatically generated is the target mode. The automatic generation of code may be initiated by developer/user command (by, for example, selecting a menu item) or automatically when the developer saves the file—storing the graphical/notify model of the user interface. As can be appreciated, changes in the notify model (as represented by the graphical user interface, in this example) results in those changes being propagated to the target model (the actual computer source code for the user interface).
A further example of a notify model and a target model is the use of code generators with Enterprise JavaBeans™ (“EJB”). In this example, an EJB is created and forms part of a notify model. An automatic code generator, applied to the EJB, generates source code objects for the particular environment for which the source code is being deployed. These source code objects form the target model.
Development tools, such as automatic code generators, enable developers to spend more time on the functions which differentiate their applications from their competitors and less time writing code for common and relatively standard user interface attributes.
Additionally, it is common in the development environment to perform tests against the notify model or the target model to ensure compliance of the application under development with various requirements. These requirements may include, for example, compliance with specifications (such as industry standards), naming conventions, as well as many others. Ensuring compliance with a specification is often referred to as validating the code.
Presently, when a change in a notify model is completed, testing of the model (e.g., validating source code or the EJB in the examples described above, respectively) is conducted against the complete target model. Additionally, testing of the target model (e.g., validation of an object model) is commenced by user command. As will be appreciated, this can be extremely time consuming. Additionally, the user may fail to invoke the testing of the target model. As a result, testing of the code is often delayed to the end of the development cycle. Delaying testing often results in defects which could have been rectified earlier in the development cycle being identified late in the development cycle. Unfortunately, the problem is exacerbated when additional code, which depends on the defects in the original code, has been developed in the interim.
Accordingly, development tools which address some of the difficulties in application development are desired.